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ABSTRACT 

Gamma Ray Bursts (GRBs) are believed to be the 
most powerful explosions that have occurred in the 
Universe since the Big Bang and are a mystery to the 
scientific community. “Swift”, a NASA mission that 
includes international participation, was designed and 
built in preparation for a 2003 launch to help to 
determine the origin of Gamma Ray Bursts. Locating 
the position in the sky where a burst originates 
requires intensive computing, because the duration of 
a GRB can range between a few milliseconds up to 
approximately a minute. The instrument data system 
must constantly accept multiple images representing 
large regions of the sky that are generated by sixteen 
gamma ray detectors operating in parallel. It then 
must process the received images very quickly in 
order to determine the existence of possible gamma 
ray bursts and their locations. The high-performance 
instrument data computing system that accomplishes 
this is called the Image Processor Electronics (IPE). 
The IPE was designed, built and tested by 
NASA/Goddard Space Flight Center (GSFC) in order 
to meet these challenging requirements. The IPE is a 
small size, low power and high performing 
computing system for space applications. This paper 
addresses the system implementation and the system 
hardware architecture of the IPE. The paper 
concludes with the IPE system performance that was 
measured during end-to-end system testing. 


National Laboratory, X-ray Telescope (XRT) and 
UV/Optical Telescope (UVOT) both built by 
scientists in Italy, the United Kingdom and at the 
Pennsylvania Sate University. BAT is to detect and to 
locate the GRB. XRT and UVOT are to study the 
afterglow of the burst [1]. 

The IPE is a data computing subsystem of 
the BAT Instrument, which resides on the Swift 
spacecraft. Its main purpose is to collect, process, 
and analyze data that will assist with the investigation 
of the origin of a cosmic phenomenon known as 
Gamma Ray Bursts. This data will enable scientists 
to probe the universe by understanding the cause of 
these bursts and quantifying the properties of the 
local environments in which these bursts occur. 

The IPE hardware controlled by the Swift 
BAT Flight Software ingests data from the BAT 
detector arrays and processes that data to determine 
the presence and location of GRBs. Once this data is 
ingested, the IPE scans the BAT data until a rate 
increase is detected, indicative of a GRB. Once 
detected, the IPE initiates the execution of the Figure 
of Merit (FOM) algorithm, which decides whether or 
not to observe the GRB and notifies the spacecraft. 
Using the Fast Fourier Transform (FFT) and back- 
projection methods, the IPE will then rapidly convert 
this map to an image to locate the GRB and transmit 
this burst position to the Swift spacecraft Command 
and Data Handling (C&DH) to enable positioning of 
the spacecraft and to alert other spacecrafts, and 
ground observations for GRB observance. 


1. INTRODUCTION 

Swift is a NASA medium-sized explorer (MIDEX) 
mission being developed by an international 
collaboration for launch in 2003. Swift shown in 
Figure 1 is the first-of-its-kind observatory for multi- 
wavelength transient astronomy. Its goal is to 
determine the origin of gamma-ray bursts and to use 
bursts to probe the early universe. Swift is comprised 
of three main instruments: Burst Array Telescope 
(BAT) built by NASA GSFC and Los Alamos 



Figure 1: SWIFT 


Power 


2 4 * 


2. SYSTEM IMPLEMENTATION 

The IPE implementation approach is the cost and 
schedule driven approach capitalizing on strong in- 
house heritage designs and expertise. The system 
architecture is designed for standardization, small in 
size, low-power, high-performance computing 
capability and high reliability for space applications. 
To achieve the high-performance computing system, 
three major activities, the data transfer throughput, 
the general-purpose processor (GPP) utilization, and 
the digital Signal Processor (DSP) performance, will 
be thoroughly reviewed and correctly selected. 
Otherwise, they might drive the design more 
complicated and cost increased, and might cause the 
system bottleneck scenario. The following sections 
discuss these activities. 

2.1 Data Transfer Throughput 

The IPE is designed to catch and alert the gamma-ray 
bursts lasting for a few milliseconds to about a 
minute. In order to achieve this objective, various 
types and sizes of data are transferred over the 
common bus in the IPE system within a specified 
time period. Depending on the science operational 
modes, the data size can be from four bytes to 64 
Kbytes per a transfer. The data rate per a transfer can 
be from the background rate of 1.35Mbps to the burst 
rate of 12 Mbps for at least 5-second period. To 
estimate the data transfer throughput margin, the data 
bus analysis is required to examine data transfer 
quantities within the system, the frequency at which 
these transfers are expected to occur and the time 
required completing these transfers. Typically, the 
common bus throughput margin should be at least 20 
%, measured over a 5-second period that includes the 
bus latency timer factored in as well as the 
probability of multi-source transfers requiring bus 
access at the same time. 

For data transfer, the IPE is designed to 
operate with minimal processor intervention. Using 
the autonomous Direct Memory Access (DMA) 
initialization, science data from each Detector Array 
is tagged and constantly transferred to IPE Bulk 
memory, via the common bus. The DMA channel 
registers are configured once by software at start up 
and can be dynamically changed by software if 
necessary. Once the initial configuration completed, 
the hardware begins the DMA transfer automatically 
without the processor intervention. This 
implementation definitely eliminates the time that 
requires the processor to initialize the DMA for each 
transfer. Especially for the multiple small-chunk data 
transfers, this implementation saves the processor 


utilization significantly. The DMA has a capacity of 
up to 64 Kbytes for each DMA transfer. 

The standard 32-bit PCI bus Rev 2.0 with 
the DMA capability built-in is selected for 
transferring data among the IPE system processor and 
other circuit card assemblies at the rate of 25 MHz 
PCI clock. The bus is implemented to allow multiple 
masters with the maximum data throughput of lGbps 
for PCI bus transfers. 

2.2 General-Purpose Processor Utilization 

The general-purpose processor should not exceed 
80% utilization, measured over a 5-second period [3]. 
The majority of the BAT flight software tasks (e.g. 
data transferring, BAT C&DH, FOV, and BAT 
science processing) will be executed by the GPP. It is 
also required to throttle the Data Ingest function to 
limit throughput such that the other tasks/activities 
within the GPP have sufficient processor resources 
(time) to complete their requirements. This throttling 
will not be activated during bright bursts, but will 
activate during long periods (>20 sec) of high-count 
rate (e.g. Solar Flares, electron precipitation events, 
etc.). This throttling method will be adjustable via 
ground command. The throttling method will be 
based on a percentage-of-the-ring-buffer-used metric. 
A typical threshold for activating the throttling will 
be around 20% (e.g. 20% is 60sec at nominal 
background event rate which would take 5-10sec of a 
fully utilized processor (assuming the nominal 
processor utilization is about 10-20%))[3]. 

To achieve these BAT non-DSP 
requirements, the selection of a high performance, 
space qualified GPP is very critical and challenging. 
Fortunately, the space qualified RAD6000 processor 
card developed by BAE System in Manassas, 
Virginia, USA is available for used as a GPP and has 
been used by the product design teams for other 
missions (Triana, SORCE, VCL.,.). RAD6000 card is 
a 32-bit Reduced Instruction Set Computer (RISC) 
processor operating at 25 MHz, providing 26 MIPS 
DRYSTONE and is selected to meet the BAT 
requirements. 

The RISC processor is well suited for 
running the real-time operating systems (i.e. 
VxWorks), the control functions, the data transfer 
and the user interfaces because of the flexibility of 
bit-byte-word operations and the flexibility of data 
interpretation. However, the RISC processor is not 
very efficient when it tries to execute the essential 
DSP algorithms (multiply, accumulate, and FFT). 
Therefore, the RAD6000 is not required to perform 
any special DSP functions. An additional processor, a 
dedicated DSP, is needed to alleviate the potential 
RAD6000 utilization problem. 



2.3 Digital Signal Processor Performance 

After the occurrence of the GRB, the data is 
processed by the DSP to determine the location of a 
GRB. The GPP will send a background subtracted 
detector map to the DSP. The DSP will convert the 
detector map to a sky map to extract and refine the 
GRB location. The DSP is required to calculate the 
1024x512 FFT-Mask convolution-inverse FFT in 4.0 
seconds. 

DSPs are designed specially for efficient 
computation with the consistency of data format of 
DSP functions. With the same data format, DSP 
architectures allow great computation throughput, but 
make poor information handling, data transfer, and 
control functions performed by the GPP. 

Based on the DSP requirements and the initial 
design analysis, a dedicated DSP is suited for 
performing the special DSP functions only. The 
selection of a space qualified 32-bit floating point 
DSP, Temic TSC 21020F, with the performance of 
40 Mflops at 20 MHz clock frequency will satisfy the 
high performance requirements of these FFT 
computations. 

3. SYSTEM OVERVIEW 

Based on the IPE hardware and software design 
teams’ extensive experiences on the PCI core design, 
RAD6000, ACTEL FGPA design, ASIC, the digital 
flight design techniques, the real-time VxWorks 
operating system (OS), “C++” and “C” programming 
languages and the flight software design, the final 
IPE architecture depicted below is implemented to 
meet the BAT IPE requirements. In addition, the PCI 
bus architecture is also selected because PCI, an 
industry standard, allows for inexpensive IPE 
simulators, and readily available Intellectual Property 
(IP) core, ground support equipment (GSE) and 
development equipment. The ACTEL PCI IP core 
with DMA controller programmed on ACTEL Rad- 
tolerant FPGA SX 54 series is implemented on the 
IPE cards designed by GSFC. 

The hardware IPE architecture is comprised 
of an enclosure, a PCI backplane, the RAD6000 
Processor Card developed by BAE Systems and four 
other circuit card assemblies developed by NASA 
GSFC that are the Multi-channel Interface Card 
(MIC) card, 1553/Memory Card, Digital Signal 
Processing (DSP) Card, and a Low Voltage Power 
Converter Card (LVPC). These components are all 
contained within the same IPE enclosure and all 
electrical connections between these components are 
made via the IPE 32-bit PCI backplane for the 
internal data transfer. Interfacing to the BAT 
Detector Array via 16 SpaceWire links, to the BAT 
Power Electronics Box via the RS-422 Asynchronous 


interface and to all other major spacecraft bus 
avionics via a Mil-STD-1553 bus, the IPE acts as the 
instrument data controller providing all software and 
internal bus scheduling, science data ingest, 
command distribution and real-time science 
operations. To increase the system reliability, two 
non-cross strapped redundant IPE boxes are required 
for the Swift mission. Only one IPE will be powered 
at a time [2]. 

The Swift BAT Flight Software applications 
run on two processors in parallel, a RAD6000 
microprocessor at 25MHz resided on the RAD6000 
Card, and a 21020 digital signal processor at 20MHz 
resided on the DSP card. Flight Software 
applications for the RAD6000 are developed using 
the ’’C++”, and “C” Programming languages. The 
Operating System is the Wind Rivers 
VxWorks/Tomado version 1.0.1. Flight software 
applications for the flight 21020 DSP device use the 
Analog Devices ADSP-21000 Family software 
development tools, with code written in C and 
assembly language. 

Three major software components that 
execute within the BAT IPE are BAT C&DH code, 
the Figure of Merit (FOM) code, and BAT Science 
code. The BAT C&DH code is to provide internal 
and external task communications, telemetry and 
command processing, memory management, 
scrubbing, system activity scheduling... The FOM 
code is to decide whether or not to observe the GRB 
and notify the spacecraft. Refer [3] for more details. 

To understand the extremely challenging 
requirements of the BAT IPE, the BAT Science Code 
(BSC) is listed and consists of at least 8 functional 
categories as follows [3]: 

1) The Data Ingest Category continually reads 
the most recent data from the Detector Array at a rate 
of 45K events/second (256KB/sec) plus 3.6K 
packets/sec (16 KB/sec) of non-event data (e.g. HK, 
command verifies, etc.). This rate increases to 240K 
events/second for at least a 5 second period. Then, 
the Data Ingest Category converts the ingested data 
into these internal data products: 

• Converts the raw pulse height of the photon 
event data into true energy scale. 

• Detector Time Histories: 9 detector areas, in 
4 E-bins, at 4 ms resolution. 

• Mask-Tagged Time Histories: 4 E-bins, 64 
ms resolution, per source. 

• Pulsar folds: 80 E-bins, 32 phase bins, per 
source. 

• Survey Detector Map: 80 E-bins, -5-minute 
accumulations, 32k detectors. 

• Background Detector Map: 4 E-bins, 8- 

second accumulation, 32k detectors. 

• Calibration accumulations (electronic pulsar 
and tagged-source events). 
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• Housekeeping data (e.g. voltages, currents, 
temps, rates, status bits, s/w-based HK 
items...) 

2) The Trigger Category searches these internal 
data products for count rate excesses indicative of 
Gamma Ray Bursts. There are two basic types of 
triggers, rate triggers ahd image triggers. 

The Rate Trigger will analyze the above 
trigger criteria. When it finds data that exceeds one 
or more of the trigger criteria, it will select an energy 
range and source and background time intervals 
based on these criteria to optimize the detection of a 
GRB by imaging, and will inform the Burst Response 
task of this selection. The burst trigger criteria will be 
evaluated for all the rate data except during the burst 
response (~5 minutes) and during slews (-20-100 
seconds). Background fits will exclude data taken 
with a different attitude or instrument configuration; 
thus the instrument will not trigger for a criterion- 
dependent time following slews, SAA passages, 
Power-Up, and any other time via ground command. 

The Imaging Trigger searches sky images 
produced by the DSP from detector maps for 
unknown sources and interesting fluctuations in 
known sources. Based on the duration of the 
increase, the trigger will initiate either a burst or 
transient response. 

3) The Burst Response Category will respond to 
the Trigger Category’s wake-up call, and analyze the 
suggested time & energy intervals and the detector 
array geometry. 

4) The Survey Products Category compresses 
the internal data products into the proper form (i.e. 
energy spectrum histograms for each of the 32K 
detectors every -5 minutes) and sends them to the 
ground. 

5) The Calibration Category uses the internal 
data products to continuously recalibrate the detector 
plane. 

6) The SOH Category collects the housekeeping 
information, passes it on to the BAT C&DH code for 
telemetry stream (both the full amount for the stored 
telemetry and a subset for the real-time telemetry), 
checks the values against the acceptable range limits, 
and sends the appropriate alarm messages for those 
items outside the acceptable range, 

7) The DSP Category is the processing of the 
detector maps from the Burst Response Category for 
the imaging of the bursts and from the imaging of the 
survey maps for the Trigger Category looking for the 
longer timescale hard X-ray transients. This imaging 
process involves both the FFT method and the Back- 
projection method. The Burst Response Category 
does the scanning of the images to identify point 
sources. 

8) The Diagnostic Category is a set of special 
modes, functions, and features in the flight software, 


plus a set of special standalone functions and 
programs (not part of the flight software), which 
allow for special data-taking modes to be 
accomplished. 


4. SYSTEM HARDWARE ARCHITECTURE 

The IPE hardware architecture is graphically 
represented in Figure 2. 



Figure 2: IPE Architecture Block Diagram 


4.1 Processor Card 

The IPE RAD6000 processor provides the central 
processing for the IPE system. Latchup immune and 
capable of sustaining up to 50 Krads of total dose, the 
RAD6000 provides a very radiation tolerant system 
for space flight applications. Onboard memory 
consists of 7 Mbytes of SRAM, 256 Kbytes Start Up 
Read Only Memory (SUROM) and 1Mbyte of 
EEPROM. This memory is used for "boot” mode 
software. The RAD6000 hosts the BAT instrument 
control, and science operation software tasks and 
supports the VxWorks commercial real time 
operating system. The processor board contains a 
low-level processor watchdog that resets the 
processor chip when processor operation is halted. 

4.2 Multi-channel Interface Card 

The Multi-channel Interface Card (MIC) implements 
a SpaceWire IPE core that controls communication 
between the IPE and 16 BAT block command and 
data handlers (BCDHs). The MIC contains a 
SpaceWire ASIC developed by GSFC that has 16 
1355 links, each of which is connected to a single 
BCDH. The MIC receives BCDH commands from 
the RAD6000 and stores them in SRAM memory. 
The MIC’s Command Data Controller then decodes 
the commands and passes them to the core, which 
distributes them to the appropriate BCDH links. 
Commands are addressable to any combination of 
links, but each command is sent to each link 
individually to prevent command loss by the 



BCDH’s. The MIC command buffer has a capacity of 
32 KBytes. 

The MIC buffers science event and 
housekeeping data received from the instrument 
BCDHs. The instrument data is DMA transferred via 
the PCI Target/DMA controller to the 1553/Memory 
card. The MIC inserts markers in the bulk memory 
data to allow differentiation of the data from the 16 
BCDHs. 

The MIC provides 32 MHz clock signals to 
the 16 BCDHs, and forwards the spacecraft 1 Hz 
clock signal to the BCDHs. 

4.3 1553/Memory Card 

The 1553/Memory Card is one card with two 
functions (1553 Bus Remote Terminal and Memory), 
which share a common interface to the PCI bus. 

The 1553 card contains a Summit 1553 
interface that enables the IPE to function as a Remote 
Terminal for communication with the spacecraft’s 
Bus Controller. This interface allows the IPE to 
communicate with other spacecraft subsystems by 
providing redundant A and B 1553 interfaces for data 
transfers. The card also contains 1 Mbyte of flight 
programmable EEPROM for enhanced mode storage. 
Two UART ports are implemented on the card to 
provide the interface with the Power Electronics Box, 
a Swift BAT subsystem. 

The Memory board provides storage for BAT 
science data until it is retrieved for processing. The 
Memory board provides 320 Mbytes DRAM storage 
of which 64 Mbytes is reserved for error detection 
and correction (EDAC). The EDAC will detect and 
correct all single bit errors and detect all multiple bit 
errors in each 32-bit word. The card implements fast 
page mode transfers as Target/DMA controller. 

4.4 Digital Signal Processor (DSP) Card 

Science data is processed by the DSP to determine 
the location of a GRB after the Rad6000 detects the 
occurrence. The DSP board consists of a PCI core, a 
Temic 21020 processor, 768 Kbytes of EEPROM for 
instructions, and 9 Mbytes of read/write RAM, split 
as shown on the P and D busses of the DSP. After the 
GRB is detected, it will send a background subtracted 
detector map to the DSP. The DSP will then convert 
the detector map to a sky map to extract and refine 
the GRB location. The combination of the DSP 
hardware plus the on-board software is able to 
calculate the 1024x512 FFT-Mask convolution- 
inverse FFT in 4.0 seconds. 

4.5 Low Voltage Power Converter Card 

The Low Voltage Power Converter (LVPC) with 
EMI filters is required to convert the primary +34 
VDC inputs received from the spacecraft into 


secondary power outputs (i.e., unswitched +3.3VDC, 
and unswitched +5 VDC). The +3. 3 VDC supply is 
capable of 7.57 amps, and the +5VDC supply is 
capable of 10 amps. The secondary power outputs 
will be used to power all of the Swift BAT IPE 
boards connected to the PCI backplane. 

4.6 Enclosure 

The IPE enclosure acts as the mechanical housing 
for the IPE unit and contains all of the IPE hardware 
assemblies. The IPE is approximately 1 1.26 in (L) x 
7.57 in (W) x 7.21 in (H) in dimension and consists 
of 10 connectors for external interfaces. The IPE 
box will be mounted on the designated panel of the 
SWIFT spacecraft mechanical structure by twelve 
(12) bolts and washers. The IPE weighs about 16.70 
pounds. The IPE enclosure is shown in Figure 3. 



Figure 3: IPE Enclosure 


5. RESULTS 

5.1 Power Dissipation 

The IPE drew between 29 to 31 Watts with an 
average steady state power of approximately 30 
Watts measured during the BAT Instrument 
interface testing. 

5.2 DSP Performance 

Currently the measured DSP performance time 
required for completing the DSP FFT requirements is 
about 35 % higher than the expected DSP 
performance time. The new compiler for the Temic 
21020 DSP and the science code optimization are 
being discussed to attempt to reduce the current DSP 
FFT computing time. 


5.3 GPP (RAD6000) Utilization 

The following graphs are the results of a test run on 
the IPE with 34K events per second of background 
science data. The Graph 1 labeled "Science Tasks" 
shows the processor utilization percentage for four 
science tasks together (i.e. Data Ingest, Trigger Task, 
Burst Response, and Science Data Products described 
in the Section 3.0 of this paper) over a period of 2000 
seconds. The Graph 2 shows the percentage of the 
processor idle task over the same period of Science 
Tasks. The Idle Task is assigned for the Bulk 
Memory Scrubbing Task, a lowest priority task in the 
systems, which is used to correct a single bit error in 
the DRAM memory due to the single event upset 
(SEU) in space. 


Normally, the IPE is required to maintain 
approximately 20% processor idle under the worst- 
case conditions. However, with a selected science 
mode, the Science Tasks shown in Graph 1 use more 
than 80% and the other higher priority tasks not 
shown use about 20% over a period of 1000 seconds. 
As a result, the Idle Task shown in Graph 2 has 
almost 0% resource left for running. In other words, 
the Science Tasks, which have higher priority than 
the Scrubbing/Idle Task, are consuming all the 
processor resources reserved for the Scrubbing Task 
to complete the science requirements as the 
Scrubbing task is postponed until the processor idle 
becomes available. The Data Ingest Task can be 
throttled/reduced by the ground command so that 
other tasks within the RAD processor have sufficient 
resources (time) to complete their requirements. 


Graph 1: Processor utilization percentage of Science Tasks 
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Graph 2: Processor utilization percentage of Idle Task 
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6. CONCLUSIONS 

The IPE hardware and software have performed well 
during the BAT instrument integration and test. The 
IPE is small in volume and light in weight but it is 
capable of performing sophisticated tasks. 

The IPE uses highly versatile architecture 
and industrial standards and provides the high 
performance in a small, reliable package. The IPE is 
an instrument data system developed for SWIFT 
BAT Instrument. However, it can be possibly used on 
the satellite that has similar requirements/architecture 
of NASA missions. 
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